Currently, a model driven approach has been widely used in software development and system management, where the model integrity is critical to guarantee that the approach can be implemented correctly.
In order to make sure the model integrity, constraints are applied for model integrity verification. Taking the model driven deployment as an example, the below constraints are required to guarantee that the deployment model can be correctly implemented in the IT environment: port unique constraint indicating all the network module deployed on the same OS should have the unique port value; collocation constraint indicating the database instance and its dependent user should be directly or indirectly hosted on the same OS; and so on.
Further, the Object Constraint Language (OCL) is a language that enables one to describe expressions and constraints on object-oriented models and other object modeling artifacts. In the prior art, OCL is widely adopted to express details about Unified Modeling Language (UML) that are either hard or even impossible to express in a diagrammatic way. The expression is an indication or specification of a value. A constraint is a restriction on one or more values of (part of) an object-oriented model or system.
Below, a standard model created by a model-constraint designer using UML language in the prior art will be described.
FIG. 1(a), (b) and (c) are model level indications created using UML language, where Class A on the left of FIG. 1(a) is a model element created for a main domain, and comprises attribute of the Class A(has its corresponding attribute), e.g. foo. Class B on the right is a composition class of Class A, i.e. a finer class divided under Class A, and Class B also has its corresponding attribute, e.g. foo 1. Class B may be indicated with an id, for example, b, and then Class B may be uniquely acquired by applying the operation of the id b to Class A. That is, operation of “Class A.b” in a system may locate from Class A to Class B via a unique path. Namely, the expression “Class A.b” may be considered as the path from Class A to Class B.
Class B may be a set, which includes several elements. For example, as shown in FIG. 1(b) which indicates a main domain of a car system. Class A indicates some kind of car, and its composition class, i.e. Class B indicates the wheels of this kind of car where four elements are included, and are front-right wheel FR-W, front-left wheel FL-W, behind-right wheel BL-W, and behind-left wheel BL-W, each element having its own attribute.
In the above system, a constraint condition may be applied to the created standard model. For example, the constraint condition may be “number of wheels is 4”. The constraint is represented as a expression of OCL language, “self.b→size( )=4”, as shown in FIG. 1(c). The meaning of the expression is that after locating to Class B from Class A uniquely, Class B is logically operated, and size of the set is resolved, that is, the number of the elements therein is calculated out, wherein “self.b” represents “Class A.b”, and “→size( )” means the logic operation performed on Class B, i.e. “Class A.b” for its size. In this example, the size thereof is 4, namely the car should have four wheels.
Then a standard model is created, and has the constraint condition as above.
In practice, a model user creates his own appreciate instance model based on the above standard model, and verifies the created instance model with the constraint condition of the standard model to check whether the created instance model is correct, that is, whether the above standard model is complied with. If a false occurs in verification, correction is required to be performed on the created instance model.
Model problem analysis is critical for model correction. In the prior art, many toolsets support validation against UML and EMF by OCL language, but there is no tool to support model problem analysis when OCL constraint violation occurs (i.e. the instance model does not comply with the constraint condition prescribed by the standard model)□ Namely, there is no tool to analyze the OCL expression to assist the model correction.
Therefore, in the prior art, when a model user, for example, a car manufacturer, has created its instance model and verifies it using the constraint condition of the standard model, if a false occurs in the instance model created by the manufacturer, namely the created instance model violates the constraint condition of the standard model, then the verification by using the standard model can only give a verification result such as “True” or “False” to the model user without more detailed information. A detailed description will be made in conjunction with FIG. 2.
FIG. 2 is a graphic representation of process creating a standard model in the prior art.
As shown in FIG. 2, the figure on the left represents the type of model to be created, and specifically a software unit “Unit” of which attribute is “version”, and it is required that a certain relationship, for example, a relationship of a hostee and host among respective units, must exist among various software units. According to the model type on the left of FIG. 2, software units WAS, JDBC, and OS (operation system)□as shown on the right of FIG. 2□are created and a constraint condition that WAS and JDBC should be hosted by the same OS is given. This constraint condition is represented as:                Context WAS        inv:self.host=self.resolve(“/JDBC”).host        
Here, “Context WAS” indicates that the constraint is started to be applied at the software unit WAS, “self” indicates the software unit WAS itself, “host” represents the software unit “OS” that WAS will be hosted thereon, “self.host” refers to the path from WAS to OS, “self.resolve(“/JDBC”)” means finding JDBC from WAS, and “self.resolve(“/JDBC”).host” indicates the path from JDBC to OS.
Verification to the instance model in the prior art will be described in conjunction with FIGS. 3 and 4.
FIG. 3 is an example of the instance model.
Assume there exists an instance model as shown in FIG. 3. When verifying whether the created instance model is correct, the above constraint expression self.host=self.resolve(“/JDBC”).host is calculated, which defines that WAS and JDBC should be hosted by the same OS. Since relationships between JDBC and WAS and between OS1 and OS2 have not been created therein, false will occur in the model verification. The result returned by the above verification is that “self.” encounters a null point and “self.resolve(“/JDBC”)” encounters a null point, namely, OS1 and OS2 cannot be reached from WAS and JDBC respectively, and subclasses cannot be obtained from the higher-level class thereof. However, the desired result in this case is that “JDBC” and “WAS” should have been hosted on the operation system. The above prior art verification cannot obtain the above result.
FIG. 4 is another example of the instance model.
In the instance model shown in FIG. 4, “JDBC” and “WAS” are hosted on different operation systems OS1 and OS2, that is, a relationship of “JDBC” to “OS1” and a relationship of “WAS” to “OS2” are created. In this case, the constraint expression self.host=self.resolve(“/JDBC”).host is operated, which defines that WAS and JDBC should be hosted by the same OS. However, a result returned by operating this expression is false. Namely, the software units WAS and JDBC are not hosted on the same operation system actually. The desired result in this case is that “JDBC” and “WAS” should be hosted on the same operation system. Thus, the above prior art verification cannot obtain the above result, either.
In fact, during verifying the instance model by applying constraint on the model, when the instance model has false, failure will occurs in the constraint applied thereon. The occurring constraint failures may be of two types: one is null node failure, that is, a return value of some node of the applied constraint is zero which indicates that the node is a null node (e.g. not defined); another is logic failure, that is, a return value of some node of the applied constraint is a wrong value which means that there is an error in the logic generating this node value.
However, the verification to an instance model in the prior art can only give verification result of “True” or “False” to the model user without providing the root cause of the model failures that the user wants to know.
If the user wants to check out the specific cause of the occurring failures, he is required to know the details of the above standard model and respective expressions therein, which is very difficult for the model user.